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DETAILED ACTION 

1 . This action is in response to correspondence filed 24 December 2008 

2. Claims 1 , 2, 4-8, 11,12, 14-22 and 24 remain pending. 

Claim Rejections - 35 USC §112 
The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

3. Applicant's amendment to claim 1 1 has been entered into the record and 
overcomes the prior rejection made under 35 USC 112, second paragraph. The 
rejection under 35 USC 112, second paragraph with respect to claims 11,12 and 14-17 
has therefore been withdrawn. 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

5. This application currently names joint inventors. In considering patentability of 
the claims under 35 U.S.C. 103(a), the examiner presumes that the subject matter of 
the various claims was commonly owned at the time any inventions covered therein 
were made absent any evidence to the contrary. Applicant is advised of the obligation 
under 37 CFR 1 .56 to point out the inventor and invention dates of each claim that was 
not commonly owned at the time a later invention was made in order for the examiner to 
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consider the applicability of 35 U.S.C. 1 03(c) and potential 35 U.S.C. 1 02(e), (f) or (g) 
prior art under 35 U.S.C. 103(a). 

6. Claims 1, 2, 4, 5, 6, 8, 11, 12, 14, 17-22 and 24 are rejected under 35 U.S.C. 
103(a) as being unpatentable over "Systems Management: Application Response 
Measurement (ARM) API" (The Open Group), hereinafter referred to as "ARM API", in 
view of Leymann et al. (US 6,633,908 B1), hereinafter referred to as Leymann. 

7. Regarding claim 1 , ARM API teaches a method for dynamically determining the 
health of a service resident on a host machine (page 3, figure 1-1), comprising: 

collecting service performance information (p. 3, fig. 1-1, measurement agent) 
from the resident service (p. 3, fig. 1-1 , client, server end systems), wherein the 
collected service information relates to a plurality of performance metrics (fig. 1-1 , 
monitor application response); and 

wherein the output comprises a plurality of service health metrics, and the 
plurality of performance metrics to provide one or more of the plurality of service health 
metrics, wherein the plurality of service health metrics comprises availability, capacity, 
throughput, service time, queue length, utilization, service level violations, and user 
satisfaction (fig. 1-1, monitor application response). 

ARM API teaches in (fig. 1-1, monitor application response) the collection of 
service performance information by an ARM API wherein the output is one of a 
scriptable interface and application programming interface (fig. 1-1, use of ARM API) 
and useable by different performance monitoring tools (fig. 1-1, measurement agent) 
but does not explicitly recite the translation of the performance information into a 
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generic output. However, in related art, Leymann teaches these features. Leymann 
teaches the utilization of an application response measurement API (fig. 1, 106) in 
communication with an API sub-agent (fig. 1 , 107) over a network wherein an agent is 
utilized for data handling and is deemed generic in order to be independent from a 
specific application and therefore the data is available for all applications requesting the 
data (col. 8, II. 3-14). In view of Leymann, it is therefore deemed that it would have been 
obvious to one of ordinary skill in the art to implement the ARM API to translate the 
collected service performance information in to a generic output. One of ordinary skill in 
the art would have been motivated to incorporate the teachings of Leymann with ARM 
API in order to implement independence from a specific application and make the data 
available for a wide range of calling applications (Leymann, col. 8, II. 9-1 3). 

8. Regarding claim 2, ARM API and Leymann teach the method wherein the host 
machine comprises one or more components, further comprising: 

collecting external performance information from one or more of the one or more 
components (ARM API, fig. 1-1, monitor application response); 

translating the collected external performance information (Leymann, col. 8, II. 9- 
13); and 

combining the translated external performance information and the translated 
service performance information to provide the generic output (Leymann, col. 8, II. 9- 
13). 

9. Regarding claim 4, ARM API and Leymann teach the method further comprising 
accessing the generic output to read the health of the service (Leymann, col. 8, II. 9-13). 
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10. Regarding claim 5, ARM API and Leymann teach the method wherein the 
collecting step comprises reading performance information provided by the service 
(ARM API, fig. 1-1, monitor application response). 

1 1 . Regarding claim 6, ARM API and Leymann teach the method wherein the 
collecting step comprises deriving performance information from the service (ARM API, 
fig. 1-1, monitor application response). 

12. Regarding claim 8, ARM API and Leymann teach the method wherein the 
deriving step comprises using a probe program to read the performance information 
(Leymann, col. 8, II. 9-13, data read by independent components). 

1 3. Regarding claim 1 1 , ARM API teaches an apparatus that determines a health of 
a service resident on a host machine, comprising: 

a data collection engine (p. 3, fig. 1-1, measurement agent) that collects service 
health information (fig. 1-1, monitor application response); 

wherein the collected service health information relates to a plurality of 
performance metrics, the plurality of performance metrics to provide one or more of the 
plurality of service health metrics, wherein the plurality of service health metrics 
comprises availability, capacity, throughput, service time, queue length, utilization, 
service level violations, and user satisfaction (fig. 1-1, monitor application response). 

ARM API teaches in (fig. 1-1, monitor application response) the collection of 
service performance information by an ARM API wherein the output is one of a 
scriptable interface and application programming interface (fig. 1-1, use of ARM API) 
and useable by different performance monitoring tools (fig. 1-1, measurement agent) 
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but does not explicitly recite the translation of the data in a health generation algorithm 
providing one or more generic health metrics. However, in related art, Leymann 
teaches these features. Leymann teaches the utilization of an application response 
measurement API (fig. 1, 106) in communication with an API sub-agent (fig. 1, 107) 
over a network wherein an agent is utilized for data handling and is deemed generic in 
order to be independent from a specific application and therefore the data is available 
for all applications requesting the data (col. 8, II. 3-14). In view of Leymann, it is 
therefore deemed that it would have been obvious to one of ordinary skill in the art to 
implement the ARM API to translate the collected service performance information in to 
a generic output. One of ordinary skill in the art would have been motivated to 
incorporate the teachings of Leymann with ARM API in order to implement 
independence from a specific application and make the data available for a wide range 
of calling applications (Leymann, col. 8, II. 9-13). 

14. Regarding claim 12, ARM API and Leymann teach the apparatus wherein the 
host machine comprises one or more external components, wherein the data collection 
engine collects external performance information from one or more external 
components (ARM API, fig. 1-1, monitor application response) and wherein the data 
analysis engine translates the collected external information using the health generation 
algorithm to provide the one or more generic health metrics (Leymann, col. 8, II. 3-14). 

15. Regarding claim 14, ARM API and Leymann teach the apparatus wherein the 
data collection engine, comprises: 
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a data query module that reads performance information from the service (ARM 
API, fig. 1-1, measurement agent); and 

a data derivation module that derives performance information from the service 
(ARM API, fig. 1-1, monitor application response). 

16. Regarding claim 17, ARM API and Leymann teach the apparatus further 
comprising an interval control engine that receives the service health information at a 
first time interval and provides an output having a second time interval different from the 
first time interval (Leymann, col. 8, II. 3-7). 

17. Regarding claim 18, ARM API teaches an apparatus that determines a health of 
a service resident on a host machine, comprising: 

a data collection engine (p. 3, fig. 1-1, measurement agent) that collects service 
health information (fig. 1-1, monitor application response); 

wherein the collected service health information relates to a plurality of 
performance metrics, the plurality of performance metrics to provide one or more of the 
plurality of service health metrics, wherein the plurality of service health metrics 
comprises availability, capacity, throughput, service time, queue length, utilization, 
service level violations, and user satisfaction (fig. 1-1, monitor application response). 

ARM API teaches in (fig. 1-1, monitor application response) the collection of 
service performance information by an ARM API wherein the output is one of a 
scriptable interface and application programming interface (fig. 1-1, use of ARM API) 
and useable by different performance monitoring tools (fig. 1-1, measurement agent) 
but does not explicitly recite the translation of the data in a health generation algorithm 
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providing one or more generic health metrics. However, in related art, Leymann 
teaches these features. Leymann teaches the utilization of an application response 
measurement API (fig. 1, 106) in communication with an API sub-agent (fig. 1, 107) 
over a network wherein an agent is utilized for data handling and is deemed generic in 
order to be independent from a specific application and therefore the data is available 
for all applications requesting the data (col. 8, II. 3-14). In view of Leymann, it is 
therefore deemed that it would have been obvious to one of ordinary skill in the art to 
implement the ARM API to translate the collected service performance information in to 
a generic output. One of ordinary skill in the art would have been motivated to 
incorporate the teachings of Leymann with ARM API in order to implement 
independence from a specific application and make the data available for a wide range 
of calling applications (Leymann, col. 8, II. 9-13). 

18. Regarding claim 19, ARM API and Leymann teach the method wherein the step 
of collecting the service performance information comprises reading first service 
performance parameters, and wherein the step of collecting the external performance 
information comprises reading first external performance parameters and deriving 
second external performance parameters (ARM API, fig. 1-1, monitor application 
response). 

19. Regarding claim 20, ARM API and Leymann teach the method further comprising 
collecting the service performance information on a first time interval and adjusting the 
first time interval to provide the generic service health output at a second time interval 
(Leymann, col. 8, II. 3-7). 
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20. Regarding claim 21 , ARM API teaches an apparatus that determines a health of 
a service, wherein the service operates on a host computer (page 3, figure 1-1), 
comprising: 

a collection module that receives performance information related to the service 
(p. 3, fig. 1-1, measurement agent); and 

wherein the output comprises a plurality of service health metrics, and the 
plurality of performance metrics to provide one or more of the plurality of service health 
metrics, wherein the plurality of service health metrics comprises availability, capacity, 
throughput, service time, queue length, utilization, service level violations, and user 
satisfaction (fig. 1-1, monitor application response). 

ARM API teaches in (fig. 1-1, monitor application response) the collection of 
service performance information by an ARM API wherein the output is one of a 
scriptable interface and application programming interface (fig. 1-1, use of ARM API) 
and useable by different performance monitoring tools (fig. 1-1, measurement agent) 
but does not explicitly recite the translation of the performance information into a 
generic output. However, in related art, Leymann teaches these features. Leymann 
teaches the utilization of an application response measurement API (fig. 1, 106) in 
communication with an API sub-agent (fig. 1 , 107) over a network wherein an agent is 
utilized for data handling and is deemed generic in order to be independent from a 
specific application and therefore the data is available for all applications requesting the 
data (col. 8, II. 3-14). In view of Leymann, it is therefore deemed that it would have been 
obvious to one of ordinary skill in the art to implement the ARM API to translate the 
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collected service performance information in to a generic output. One of ordinary skill in 
the art would have been motivated to incorporate the teachings of Leymann with ARM 
API in order to implement independence from a specific application and make the data 
available for a wide range of calling applications (Leymann, col. 8, II. 9-1 3). 

21 . Regarding claim 22, ARM API and Leymann teach the apparatus wherein the 
collection module receives external performance information from one or more external 
services coupled to the host computer and receives internal performance information 
related to operation of the service on the host computer (ARM API, fig. 1-1, monitor 
application response). 

22. Regarding claim 24, ARM API and Leymann teach the apparatus wherein the 
generic health metrics is one of a scriptable interface and an application programming 
interface (ARM API, use of API for response measurement). 

23. Claims 7 and 15 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
ARM API and Leymann in view of Chappelle (US 5,949,976). 

24. Regarding claim 7, ARM API and Leymann do not explicitly teach of using a 
wrapper program. Chappelle teaches about using a wrapper program (performance 
monitoring and graphing tool) to read the performance information (col. 3, II. 29-32). 
The examiner is interpreting wrapper program as any program that is used as an 
interface program because this gives the broadest reasonable interpretation. In ARM 
API's specification, the performance forecasting system communicates with one or 
more monitoring system (fig. 1-1 , enterprise management solutions). It would have 
been obvious to one of ordinary skill in the art at the time of the applicant's invention to 
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utilize the teaching of Chappelle in regards to using a wrapper program because it 
would have allowed the performance forecasting system to read the information 
supplied by various monitoring systems regardless of the components particular 
infrastructure. One of ordinary skill in the art would have been motivated because this 
modification would result in a more versatile system as outlined above. 

25. Regarding claim 15, ARM API and Leymann do not explicitly teach of using a 
wrapper program. Chappelle teaches about using a wrapper program (performance 
monitoring and graphing tool) to read the performance information (col. 3, II. 29-32). 
The examiner is interpreting wrapper program as any program that is used as an 
interface program because this gives the broadest reasonable interpretation. In ARM 
API's specification, the performance forecasting system communicates with one or 
more monitoring system (fig. 1-1 , enterprise management solutions). It would have 
been obvious to one of ordinary skill in the art at the time of the applicant's invention to 
utilize the teaching of Chappelle in regards to using a wrapper program because it 
would have allowed the performance forecasting system to read the information 
supplied by various monitoring systems regardless of the components particular 
infrastructure. One of ordinary skill in the art would have been motivated because this 
modification would result in a more versatile system as outlined above. 

26. Claim 16 is rejected under 35 U.S.C. 103(a) as being unpatentable over ARM 
API and Leymann in view of Walrand et al. (US 6,647,413), hereinafter referred to as 
Warland. 
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27. Regarding claim 1 6, ARM API and Leymann do not explicitly teach of a weighting 
scheme that weights one or more performance information parameters; a summation 
scheme that combines one or more performance information parameters; and a 
averaging scheme that averages collected service health information for a service 
health metric. However, Walrand teaches on these aspects. Walrand teaches about a 
summation scheme that combines one or more performance information parameters 
(col. 7, II. 32-33) and an averaging scheme that averages collected service health 
information for a service health metric (col. 7, II. 55-57). In HPCN Walrand teaches of a 
weighting scheme that allocates different level of importance to different parameters (p. 
2). One objective of Walrand invention is to optimize the network performance (col. 2, II. 
53-54). It would have been obvious to one of ordinary skill in the art at the time of the 
applicant's invention to utilize the above mentioned features of Walrand's into ARM API 
and Leymann because adding these features to ARM API and Leymann would allow 
focus on specific parameters (using the weighting scheme) and give information 
regarding the overall performance of the network system (using the summation and 
averaging schemes). These added features would allow ARM API and Leymann to 
provide a healthy network and more effectively predict failure of registered computing 
devices (col. 2, II. 25-34) resulting in a more efficient performance forecasting system. It 
is for this reason that one of ordinary skill in the art at the time of invention would have 
been motivated to make the above-mentioned modifications. 
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Response to Arguments 

28. Applicant's arguments filed 24 December 2008 have been fully considered but 
they are not persuasive. 

Claim 1 

29. With respect to the rejection of claim 1 under 35 USC 1 03(a) in view of ARM API 
and Leymann (US 6,633,908), the applicant argues (a) that Leymann does not disclose 
or suggest "use of a generic output" and (b) that Leymann and ARM API cannot be 
combined because Leymann is distinct from ARM API. The examiner respectfully 
disagrees with the applicant's position. 

30. (a) With respect to teaching the "use of a generic output" the examiner maintains 
that Leymann teaches on this broadly claimed aspect wherein Leymann teaches in 
column 8, lines 3-14 the making of data available for all applications requesting the data 
by use of an invocation agent. The invocation agent provides the data needed by calling 
applications and is considered a generic component due to its independence from 
specific applications. Because of the independence of the invocation agent, the data it 
provides is therefore considered to be "generic output" as required by the claims. The 
output provided by the invocation agent is deemed generic because it is made available 
for all applications. The ARM API non-patent reference is relied upon for teaching the 
further aspect of having the output data in a scriptable interface for application 
programming interface wherein ARM API teaches in Fig. 1-1 the use of the application 
response measurement API. 
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(b) In response to applicant's argument that there is no suggestion to combine 
the references, the examiner recognizes that obviousness can only be established by 
combining or modifying the teachings of the prior art to produce the claimed invention 
where there is some teaching, suggestion, or motivation to do so found either in the 
references themselves or in the knowledge generally available to one of ordinary skill in 
the art. See In re Fine, 837 F.2d 1071 , 5 USPQ2d 1596 (Fed. Cir. 1988)and In re 
Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). In this case, the examiner 
maintains that one of ordinary skill would have been motivated to make a data output a 
generic form as taught by Leymann. The examiner maintains that one of ordinary skill 
would have been motivated to utilize Leymann in combination with the ARM API 
reference for the same reasons set forth in argument (a) and specifically implement 
independence from a specific application and make the data available for a wide range 
of calling applications as taught by Leymann in column 8, lines 9-13. 

The applicant did not present any additional substantial arguments. The 
remaining claims stand rejected for the same reasons set forth with respect to claim 1 . 
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Conclusion 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Benjamin Ailes whose telephone number is (571)272- 
3899. The examiner can normally be reached Monday-Friday, IFP Hoteling schedule. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Andrew Caldwell can be reached on 571-272-3868. The fax phone number 
for the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 
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Examiner, Art Unit 2442 
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Supervisory Patent Examiner, Art 

Unit 2442 



